home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / mint / l_0399 / 27 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  2.6 KB
  1. From: Julian F. Reschke <julian@GINA.UNI-MUENSTER.DE>
  2. Subject: Re: libraries
  3. Date: Mon, 18 Jan 93 12:38:31 MET DST
  4. In-Reply-To: <9301180318.AA05532@terminator.rs.itd.umich.edu>; from "Michal Jaegermann" at Jan 17, 93 8:16 pm
  5.  
  6. > Still, in my opinion, a requirement for something like an explicit
  7. > #include <tos/foo.h> would be a mistake which will cause immediate
  8. > compatibility headaches, neccessity to edit sources, lotsa of
  9. > superfluous #ifdef...#endif and the like.
  10.  
  11. Why? The idea is basically to keep the old header files for compatibility,
  12. and to use the new standardized header files for new programs.
  13.  
  14. > I think that instead we should modify a little bit an organization
  15. > and a compiler driver.  Let us assume that we have two different files
  16. > .../include/tos/stdio.h and .../include/mint/stdio.h.  In sources
  17. > one should have one, unequivocal, directive '#include <stdio.h>'.
  18. > A compiler driver (like gcc, for example) with a flag '-tos' should
  19. > search for header files like this:
  20. >   .../include/tos/,.../include, <whatever else in include path>
  21. > and with '-mint' flag like this:
  22. >   .../include/mint/,.../include, <whatever else in include path>
  23. > with a similar arrangement for libraries.  One of flags '-mint' '-tos'
  24. > could/should be a default depending on a compiler configuration.
  25. > You risk that way at most a neccessity to recompile a driver, which
  26. > is really small program and can be redone even on the smallest
  27. > machines.  So what are your comments?
  28.  
  29. This is exactly what I don't want. Let's have the same header files, no matter
  30. what compiler is used, what architecture is used or whether MiNT is used
  31. (should be used all the time :-).
  32.  
  33. > Julian asks why DTA is named _DTA in gcc header files.  I can guess
  34. > that this was done to be consistent with a convention that
  35. > internal "vendor names" start with '_' to avoid a polution of a name
  36. > space.  If Pure C needs DTA instead this is easy to resolve by
  37. > supplying in a "compatibility" header file "#define DTA _DTA".
  38. > As for conflicts in prototypes I really cannot tell.  I have never
  39. > seen Pure C compiler and I do not know where conflicts do occure.
  40. > I can only tell that gcc headers try very hard to follow ANSI C
  41. > Standard and comparing with other "more or less" Standard C compilers
  42. > on other machines are pretty good at it.
  43.  
  44. If this is the reason, this should be done with all structures. However,
  45. I still prefer to use the original names defined by Atari.
  46.  
  47. -- 
  48. ________________ cut here _________________________
  49. Julian F. Reschke, Hensenstr. 142, D-W4400 Muenster
  50.   eMail: julian@math.uni-muenster.de, jr@ms.maus.de
  51. ________ correct me if I'm wrong __________________
  52.